Refuse tokens that carry no groups claim - #17

The problem

The workspace is gated in two places on purpose — Authentik binds the
application to the dropbox group, and the app re-checks the groups claim.
The second check exists precisely so the workspace does not depend on the first.
But when the claim was absent, it fell back to trusting the first — in the one
case where the backstop was the only thing left to do its job.

Absence of the claim does not mean the user belongs to nothing. It means the
provider's configuration has drifted, and the honest answer to "is this user a
member?" is that we cannot tell. So we stop saying yes.

Checked before changing the default

Locking the only two members out of their own file store would be a poor way to
discover the mapping was broken, so this was verified against the live provider
rather than assumed:

• A Beckham Share - OIDC groups scope mapping is bound to the provider,
  returning {"groups": [group.name for group in request.user.ak_groups.all()]}.
• Evaluated against both real accounts it yields a populated list containing
  dropbox.
• The app requests the groups scope — confirmed in the authorization request
  the live provider accepts.
• The current log window covers four sign-ins and zero fallback warnings.

Nobody is relying on the fallback, and existing signed-in sessions carry the
claim, so no one is logged out by this.

The escape hatch

ALLOW_MISSING_GROUPS_CLAIM, default false.

Kept deliberately. If that scope mapping ever breaks — an Authentik upgrade, a
fat-fingered edit — the failure mode without a lever is "both members locked out
of their own files while someone repairs an identity provider under pressure".
That is its own kind of outage.

It re-opens the gap it exists to close, so it is not quiet about it: the app
logs a warning at startup for as long as it is set, and again on every
admitted request. docs/SECURITY.md says to clear it once the mapping is fixed.

Verification

Backend suite: 28 tests pass, including three new ones — a groupless token
is refused at /app, is refused by the management API, and is admitted only
when the flag is deliberately set.